In a pervasive (or ubiquitous) computing environment (PCE), computers and sensors are integrated into the user's surrounding environment, thus creating a convenient, information-rich atmosphere. In such an environment, it is expected that users will interact with many interconnected and smart devices, as well as with service providers, for accessing information and services of interest in a highly transparent manner. This field is commonly seen as the future of computing, when computational power will be available everywhere.
Despite the great potential of such solutions in providing new and improved services, their very own pervasive nature raises some important security concerns: on the one hand, from the service providers' perspective, it is important to prevent unauthorised users from accessing some (potentially paid) services, which has implications for the need for deploying billing, authentication and access control mechanisms; on the other hand, authorised users may want to keep their privacy when accessing those services. Therefore, in order to assure the success of PCEs, it is important to create a solution that combines these conflicting requirements.
This can be understood by considering a scenario shown schematically in FIG. 1, in which a user wants to access some protected service (or a group of them) whose identification is SID, offered by a Service Provider P 11. In order to do so, the equipment U 10 used by the user needs to have valid credentials issued by the Authentication Server S 12. These credentials (e.g. a certificate or a shared key on a smart card, e.g. SIM/USIM/ISIM, which is an application that typically runs on a Universal Integrated Circuit Card (UICC)) not only give access to the service, but also contain an access profile linked to the SID, denoted pfl, that determines the extent of the user's rights for that service; for example, in addition to the SID information, pfl may contain an expiration date or a usage limit or more general conditions under which the service is to be used. Therefore, using a valid credential, U 10 can access the specified service according to permissions and rules expressed by the corresponding pfl. It should be noted that U in this context can be understood as many different types of entities: a person, an electronic device, computer program, etc., but in practice U 10 refers to the equipment used by a user to access the PCE and its offered services.
In a commercial scenario, S 12 will deliver the requested credentials to U 10 only if some requirements are fulfilled, such as the payment of a fee per access or the acquisition of a service subscription. Thus, when trying to access the service, users are requested to prove that they can indeed do so, for example by presenting a payment receipt R. In order to prevent abuse, R should be bound to the user and to the requested service with the corresponding usage rights, thus enclosing the user identity and pfl; additionally, R must also have some unique identification and a valid signature from a Billing Authority B 13, the entity responsible for handling payments.
It will be noted that such a receipt may not be strictly necessary, since S 12 may have access to a database containing the payment status of all users (e.g., if S 12 and B 13 are implemented as a single entity), or can contact B 13 and charge the user dynamically (e.g., in a scenario where B 13 is a Mobile Network Operator and U 10 is a valid subscriber).
In this context, unless the users intentionally disclose their private information (or in case of users' misconduct attested by trusted authorities, i.e. a Lawful Interception scenario), a highly privacy-preserving system must ensure that: the real identity of the user interacting with the service is not revealed; different sessions are not linkable; the user's context information (e.g., location, type of service requested, usage preferences) is not disclosed to unauthorised entities; the communication between user and service is secured by means of confidentiality and integrity mechanisms.
Traditional access control schemes commonly rely on the pre-established trust relationship between users and service providers, which can be ascertained by means of security credentials issued by an Authentication Server (e.g., as in Kerberos). The actual structure and usage of such credentials depends on the system security requirements. For example, services provided by student campus PCEs usually are not too restrictive, and credentials that allow access until revoked may be enough. In comparison, commercial scenarios may require some special conditions to be met before the access is granted (e.g., the credentials acquired may have an expiration date associated to a subscription, or the credentials can be used only a limited number of times), especially for paid services. Note also that from the user's perspective, it is rather cumbersome to handle per-service pre-established trust, usually implying per-service unique username/password etc. Relying on a separate, service-independent authentication server is usually more convenient, but may create linkability and reduction of privacy as discussed below.
One significant issue with conventional access control solutions is that they tend not to protect the users' privacy, since the owner of the credential can be identified or at least be tracked (by the Service Provider and/or by external entities) whenever it is used for accessing some service. In order to address this subject, some schemes have proposed the adoption of blind signature schemes, which prevents any entity (including the Authentication Server) from establishing a relationship between an issued credential and its owner. However, the usage of blind signatures in these schemes prevents the Service Provider from imposing any constraint (e.g., an expiration date) to the signed credentials, which is especially undesirable in commercial scenarios. Although this specific problem could be solved simply by the deployment of so called partially blind signatures instead of purely blind ones, existing proposals also display some performance limitations (e.g., the number of asymmetric cryptographic operations performed) and/or security flaws (e.g., improper user authentication procedure) and/or may still have privacy flaws (e.g. various forms of traceability of the user being possible).
In the context of 3GPP mobile networks, the mobile infrastructure can be used to leverage many security-related services by means of the 3GPP defined Generic Authentication Architecture (GAA), which provides authentication and key agreement (AKA) mechanisms for applications and services. The use of GAA brings many advantages, not only in terms of client-side computational costs and management of credentials, but also in terms of privacy: even without revealing their identities, GAA-enabled users can establish shared keys with GAA-enabled service providers whenever needed. However, GAA offers no privacy from the point of view of the Mobile Network Operator (MNO) itself: since the MNO is responsible for creating the keys upon the reception of some user-identifiable information, this entity can easily identify the user behind every key request and eavesdrop any communication protected by these keys. Although the MNO can be considered trustful in many scenarios, the trust-level may not always be sufficient, especially for applications involving financial transactions, medical information or other security-sensitive data.
It is thus desirable to provide user privacy, user authentication, access control and accountability capabilities for commercial pervasive scenarios in a lightweight fashion, while avoiding issues appearing in existing solutions. It is also desirable to combine these with the features provided by GAA.